Polyscheme: a Semantics for a Concurrent Scheme 1 Current State of Scheme 2 Semantics of a Concurrent Scheme

The Scheme language does not fully specify the semantics of combination: the evaluation order of the terms composing a combination is left indeterminate. We investigate in this paper a diierent semantics for Scheme where terms of combinations are evaluated concurrently. The resulting semantics models a language with concurrent threads sharing a common workspace. The semantics is given in terms of denotational semantics and uses resumptions as well as a choice operator: oneof which mimics a scheduler. An alternate deenition for this operator lets appear the classical powerdomains. The main interest of this operator is to ooer a formalization that can be read with an operational point of view while keeping a rm theoretical base. Scheme also ooers rst class continuations with indeenite extent; we examine some semantics for continuations with respect to concurrency. Each of these semantics is a natural extension of the sequential case of regular Scheme. Still they strongly diier in their observed behaviours. The resulting language, named PolyScheme, ooers much of the features of current concurrent Lisp (or Scheme) dialects thanks to the sole extension of its combination semantics and without any explicit specialized construct dealing with concurrency. The Scheme language Rees & Clinger 86] does not specify the evaluation order of the terms of a combination i.e. application. The usual behaviour for Lisp-like languages is to evaluate terms from left to right due to the nature of lists which head is easily extracted. Clever compilers can improve the generated code if they can rearrange the computation of the arguments of the application provided that no side-eeects occur. Scheme goes further since not only the arguments of the application can be computed in whatever order but so can be the functional term. Moreover side-eeects must explicitely be sequentialized thanks to begin (or progn in Lisp). Nevertheless Scheme is always a sequential language since the body of a function is computed after its arguments. To say that the evaluation order is indeterminate only means that there exists a sequential evaluation order but it is left unspeciied. Thus one must not write code depending on it. This remark is crucial since the following Scheme program always returns true: (let ((x 1)) (car (list (equal? x x) (set! x 2)))) During the comparison, performed by equal?, the variable x is equal to 1 or 2 depending on the evaluation order but in any case will always be equal to itself. …